Hi Dai Gei Ho~ 我是Winnie～

今天是中秋連假的第一天，（而聽主管說 通常連假什麼的最容易在鐵人賽中殞落XD）， 所以為了證明我還沒殞落，希望大家今天還有看到我的第六篇文章 XD

回到正題，在昨天的文章中，我們比較了 常見打包工具（Webpack） 與 Vite 各自的 dev-server(本地伺服器) 特點與 運作模式 。 但後來在夜深人靜時 我才驚覺自己沒說到關於 Vite 的 Production Build 運作方式XDD，所以在今天的主題將 補充於上篇，來說說 Vite 的 Production Build。

Vite 的 Production Build

與 Vite 開發環境使用 原生ESM 運作模式 的不同， 在Production的環境下，Vite與 webpack 一樣，也就是採取 傳統Bundle的方式來進行 編譯壓縮檔案， 所以 當我們 在終端機下 yarn build 時，也就會發現在dist資料夾中的 index.js也是一大包，所有哩哩叩叩的程式碼都會在裡面。

文章說到這邊～ 你可能會想問 那為什麽不使用 Native ESM 呢？

針對這個問題，Vite在官方文件中也做了解釋：

Vite does utilize bundling for production builds, because native ES module imports result in waterfall network requests that are simply too punishing for page load time in production.

大致意思是說，雖然目前 Native ESM 得到了瀏覽器 廣泛的支援，但因為 模組之間的import 會產生 一大串的模組引入 依賴鏈。因此也就造成 瀏覽器 就必須等這些模組全部 下載 完後才能開始執行檔案，而當依賴鍊很長串 對 瀏覽器而言就很容易造成依賴過載等待時間過長 的問題，而這就是 上述官方文件所說 waterfall network requests。

一大串依賴鍊是什麼？

簡單來說就像上圖一樣，一台超長聯結車，車頭連結A車廂，而A廂又必須連結B車廂，就這樣一直連啊連，最後產生的一串很長的依賴鍊。而你今天要開這台聯結車的話，到達目的地就會花費很久時間，而 模組引入的依賴鍊 也是這樣的意思。

所以至少現在對於 Vite來說 Native ESM 目前還是 不太適合 使用在 production 的環境下，但也不難保證未來可以解決這個問題，因為其實已經有套件開始試著在解決了XD。

Vite 使用的 Build 工具

再公布 Vite 使用哪個 Build 工具之前，我們先來看看 尤雨溪大大 與 Webpack創辦人的對話

對的，很明顯XD，Vite不是使用Webpack來進行打包，而是使用 rollup。

為什麼選擇 Rollup呢？

事情是這樣的，由於 Vite主要還是以 原生ESM為主的前端建構工具，而在選擇打包工具時可能也是希望可以選擇 基於原生ESM的打包工具。

而剛好Rollup就符合此需求，不僅是基於ES2015的打包工具，而最大特色還可以透過較快的時間來將檔案打包成更小容量。

然後我們再從 以下rollup.config.js來看看

// rollup.config.js
import babel from 'rollup-plugin-babel';

export default {
    input: './src/index.js',
    output: {
        file: './dist/bundle.rollup.js',
        format: 'cjs'
    },
    plugins: [
        babel({
            presets: [
                [
                    'es2015', {
                        modules: false
                    }
                ]
            ]
        })
    ]
}

從上程式碼們可以看出，Rollup 使用起來十分簡潔，config 使用的是ESM同時 可以支持相對路徑的寫法。

因此綜合以上優點，Vite 選擇了Rollup。

最後 謝謝大家的閱讀 以上是今天的文章。